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METHODS AND APPARATUS FOR BOOTING 
A COMPUTER HAVING A REMOVABLE 
MEDIA DISK DRIVE 


FIELD OF THE INVENTION 


This invention relates generally to storage subsystems for 
computer systems. In particular, this invention relates to 
removable media storage devices configured as fixed disks 
in computer systems and methods and apparatus for booting 
the operating system from such devices. 


BACKGROUND OF THE INVENTION 


In recent years, personal computers (PCs), which includes 
work stations and the like, have grown increasingly sophis- 
ticated. During this period, the programs that run on PCs 
have increased in complexity and, correspondingly, in size. 
As a result, the capacity and usefulness of the current floppy 
disk drive, a standard feature in many PCs, have been 
surpassed by the programs it was designed to bear. Whereas, 
software developers previously distributed their products via 
floppy disk, they have increasingly been forced to use 
alternative methods, such as CD-ROM. 

Despite the trend against the usefulness of the floppy disk 
drive, the need for the removability that the floppy disk drive 
provides has remained—primarily as a tool to provide 
diagnostic support in the event of a system failure. For 
example, if the fixed disk drive becomes corrupted, users 
turn to the floppy disk drive to attempt to recover. However, 
the limited capacity of a floppy disk poses severe constraints 
on the sophistication of the diagnostic tools that can be used. 
Vander Kamp et al., U.S. Pat. No. 5,418,918, suggests 
CD-ROM drives as a way of overcoming this problem. 
Unfortunately, CD-ROMs need special BIOSes and limit the 
user to the tools supplied by a particular software vendor. As 
a result, the user is unable to mix and match his preferred 
tools. 

Recent years have also witnessed the development. of 
removable media drives that have storage capacities char- 
acteristic of fixed disk drives and removability characteristic 
of floppy disk drives. These removable media drives have 
the capacity to store sophisticated diagnostic tools. 
Moreover, unlike CD-ROM drives, the user has the capa- 
bility to customize the software on the media to suit par- 
ticular needs. However, to fully utilize the capacity of such 
a removable media drive, in the current PC environment, it 
must be configured as a fixed disk. This requirement has 
complicated the integration of removable media drives into 
the PC system. For example, the typical PC attempts to test 
all drives before starting the boot sequence. If the removable 
media drive has no media, it will fail the test and not be 
recognized by the operating system after the system is 
booted. Thus, there is a need to allow the system to boot and 
recognize removable media drives, even when no media is 
present during the boot process. 

If users could boot directly from a removable media drive, 
tremendous flexibility would be gained in, for example, 
diagnosing fixed disk failures. The capacity of removable 
media drives is such that a user can have a complete 
operating system customized to his/her desire along with 
diagnostic utilities of his/her choice. Unfortunately, conven- 
tional PCs only permit users to boot from the floppy “A” 
drive or the fixed “C” drive. If the removable media drive is 
configured as the “C” drive, conventional personal computer 
systems constrain the user to always have bootable media 
present in the drive at system start-up. Furthermore, the 
users ability to swap media in the removable media drive 
during system operation is also severely inhibited. 
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Thus, there is a need for methods and apparatus for 
booting a computer from a removable media drive config- 
ured as a fixed disk drive, without imposing any constraints 
on the users flexibility. 


SUMMARY OF THE INVENTION 


The present invention is particularly well suited for use in 
booting the Microsoft Disk Operating System into a Per- 
sonal Computer systems (PC) via a removable media disk 
drive. According to an aspect of the present invention, the 
method of booting from any storage device attached to the 
processor of the personal computer comprises several steps. 
First, a read request to provide a master boot record from a 
storage device attached to the PC is made. Second, rather 
than retrieving a conventional master boot record, a substi- 
tute master boot record is received. Second, the substitute 
master boot record, confined to the constraints of the original 
master boot record, retrieves a universal boot program from 
the storage device. Third, the universal boot program scans 
all storage devices for bootable partitions. Fourth, the uni- 
versal boot program loads a bootable partition as directed by 
a user and replaces the drive number in the boot sector. Fifth, 
the universal boot program waits for the operating system to 
load into the PC and changes the operating system code to 
the drive from which the boot sector was obtained. 

According to another aspect of the present invention, a 
method and apparatus are provided for booting from any 
cartridge. This aspect allows a cartridge that was formatted 
on any PC with any CMOS settings to boot from the PC 
utilizing this aspect of the invention. For example, a SCSI 
formatted cartridge will boot on an IDE removable disk 
drive that embodies the present invention. 

According to another aspect of the present invention, the 
removable media drive simulates the presence of media 
during booting of the operating system such that the oper- 
ating system determines that the drive is available. 

According to another aspect of the present invention, the 
removable media driver is loaded before the operating 
system and attached to the operating system after the oper- 
ating system is sufficiently loaded into the PC. As a result, 
a user is not required to add a driver to the DOS CONFIG- 
SYS file. 

According to another aspect of the present invention, a 
driver for the removable disk drive encapsulates the oper- 
ating system disk services driver. The driver for the remov- 
able disk drive captures all calls to the removable drive and 
handles removability functions. Other calls, common to 
fixed disks are passed to the disk services driver provided by 
the operating system. 

Additional features and advantages of the present inven- 
tion will become evident hereinafter. 


BRIEF DESCRIPTION OF THE DRAWINGS 


The foregoing summary, as well as the following detailed 
description of the preferred embodiments, is better under- 
stood when read in conjunction with the appended drawings. 
For the purpose of illustrating the invention, there is shown 
in the drawings embodiments that are presently preferred, it 
being understood, however, that the invention is not limited 
to the specific methods and instrumentalities disclosed. In 
the drawings: computer system. 

FIG. 1 is a block diagram of a conventional computer 
system. 

FIG. 1A is a block diagram of removable media drive 
controller hardware in accordance with a preferred embodi- 
ment of the present invention. 
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FIG. 1B is a graphical depiction of the command block 
registers specified in an IDE interface. 

FIG. 1C is a state diagram of the operation of the 
removable media drive of the present invention. 

FIG. 2 is a flow chart of an operating system booting 
sequence incorporating an embodiment of the present inven- 
tion. 

FIG, 2A is a flow chart of the removable media drive 
response to boot sequence testing, in accordance with the 
present invention. 

FIG. 2B is a flow chart of the process of the substitute 
master boot record (UBR) gaining control of the boot 
sequence in accordance with the present invention. 

FIG. 2C is a flow chart of the process of the UBP finding 
and loading a valid boot sector, in accordance with the 
present invention. 

FIG. 2D is a flow chart illustrating the operation of a 
removable media driver in accordance with the present 
invention. 

FIG. 3A is a graphical depiction of an operating system 
driver environment before the removable media driver of the 
present invention is loaded. 

FIG. 3B is a graphical depiction of the DOS driver 
environment after the removable media driver of the present 
invention is loaded. 


DETAILED DESCRIPTION OF THE 
INVENTION 


A preferred embodiment of the invention will now be 
described with reference to the FIGURES. In the drawings, 
like numerals indicate like elements throughout. The 
description given herein is for exemplary purposes only and 
is not intended in any way to limit the scope of the invention. 
For example, the computer system and operating system 
environment described herein are merely exemplary and are 
not intended to limit the invention. All questions regarding 
the scope of the invention may be resolved by referring to 
the appended claims. 

The sections below describe in further detail the system 
for integrating a removable media drive into a PC system. 
There are a variety of ways that such a drive can be 
integrated into a PC system. Section I details an exemplary 
PC system having an attached removable media disk drive. 
Section II follows with details of a presently preferred 
embodiment of a removable media drive that connects to the 
PC system via an IDE interface. That section also provides 
a description of the various states of the removable media 
drive as a function of media insertion and removal. A user 
of such a PC system, may configure the removable media 
drive in order to facilitate booting, or merely to access the 
drive after the boot process has completed. Thus, section III 
details a presently preferred embodiment of a method of the 
invention for assigning a drive letter and allowing the 
system to boot from the removable drive. Additionally, after 
the boot process is completed, the operating system cannot 
communicate directly with the removable drive. Extensions 
must be added to the operating system to enable the aspects 
of removability. According to a further aspect of the method 
of the present invention, section IV provides details for 
integrating a software driver into the operating system 
before the operating system has loaded. 

L System Overview 

FIG. 1 is a block diagram of an exemplary computer 
system, such as an IBM PC or a system functionally 
compatible with the IBM PC, in which the present invention 
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may be employed. Such a system is composed of a variety 
of subsystems. The more significant subsystems include the 
processor, the storage device subsystem 250, and other 
support devices, such as the video system (e.g., a display 
240), a keyboard and the like (not shown). 

Each of these subsystems is, in turn, made up of a variety 
of components. For example, and as used herein, the pro- 
cessor 220 represents a subsystem that comprises a CPU 
222, random access memory (RAM) 224, read-only memory 
(ROM) 228, CMOS memory 226, an internal bus 221 to 
allow communication between the CPU 222 and its 
components, an AT bus 223 for connecting external devices, 
and controller cards 225, 227 connected to the AT bus 223 
for communicating with other subsystems. For example, the 
storage device subsystem 250 will be interfaced to the 
processor 220 via a disk controller card 227. Similarly, a 
storage device subsystem 250 may comprise a plurality of 
storage devices, where each storage device may be one of a 
fixed disk drive 230, a removable media drive 210, a floppy 
disk drive (not shown), a magnetic tape drive (not shown), 
a CD-ROM drive (not shown) or the like. 

The present invention relates to the relationship of the 
removable media drive 210 to the processor 220. 
Importantly, removable media drives have attributes of both 
fixed disk drives and floppy disk drives. Like fixed disk 
drives, removable media drives have much higher storage 
capacities and data transfer rates than currently available 
floppy disk drives. On the other hand, like floppy disk 
drives, the drive media of the removable media disk drives 
can be removed and replaced during the normal operation of 
the PC. These and other differences between fixed disk 
drives and floppy disk drives have resulted in PC operating 
system software and Basic Input/Output System (BIOS) 
code treating the two types of drives differently. For 
example, in a conventional IBM-compatible PC employing 
the DOS operating system floppy drives are configured as 
drive “A” or “B” and are configured as 1.2 or 1.44 mega- 
bytes. Fixed disks are configured as drive “C,” “D” and so 
on and are configured with a cylinder, head and sector 
number that relates to the capacity of the drive. The cylinder, 
head and sector configuration allows capacities on the order 
of gigabytes. Significantly, at present, removability of fixed 
disk media is not fully supported by such a PC. Thus, a 
removable media drive cannot be simply configured as a 
fixed disk drive. The PC will not fully recognize its remov- 
ability attributes, and problems will result. 

In the storage device subsystem 250 of FIG. 1, several 
components in the PC 200 must interact to properly connect 
the processor 220 to the storage device(s) 250, particularly 
the removable media drive 210. Among those components 
are a disk controller card 227, a storage device (i.e., the 
removable media drive 210), a software driver residing in 
RAM 224, and a BIOS stored in ROM 228. Additionally as 
with a fixed disk drive, when the PC 200 is configured with 
the removable media drive 210, settings are stored in CMOS 
memory 226 (an area of memory that retains its values when 
the power is removed from the PC) that indicates the various 
parameters of the removable media drive 210 to the BIOS 
228. Of particular relevance, these CMOS settings contain 
parameters (e.g., the number of logical cylinders, heads and 
sectors) that are used to communicate data between the 
processor 220 and the removable media drive 210. 

To enhance the reliability of the connection between the 
processor 220 and the storage subsystem 250 and to enhance 
the interchangability of storage devices, several standard 
storage device interfaces have emerged since the introduc- 
tion of the PC. For example, the Small Computer System 
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Interface (SCSD and the Integrated Drive Electronics (IDE) 
interface are among the more popular standard interfaces. 
The presently preferred embodiment utilizes an IDE 
interface, although those skilled in the art should recognize 
that features of the present invention will work equally well 
on other interfaces, such as SCSI. 

To ensure compatibility between controller cards and 
storage devices from a variety of different vendors, a storage 
device must conform to industry standards. In the case of 
IDE, those standards are documented in the proposed 
American National Standard on Information Technology— 
AT Attachment Interface With Extensions (ATA-2), Jan. 17, 
1995, which is hereby incorporated by reference. 

In a conventional PC that uses an IDE interface, the 
processor will have an IDE interface controller card (e.g., 
227) attached to the AT bus 223. When the processor 220 
requires data from the removable media drive 210, the 
processor 220 will access the drive 210 through the standard 
IDE interface controller card 227. Moreover, in a typical PC 
200, particularly one that uses the Microsoft Disk Operating 
System (MS-DOS), the operating system will communicate 
with the IDE storage device through a device driver. The 
device driver is conventionally loaded into the system by 
MS-DOS. According to an aspect of the present invention 
and as will be explained more fully below, because the PC 
may communicate with the removable media drive 210 
before MS-DOS has loaded, it is advantageous to load the 
removable media driver before MS-DOS has loaded. 

Il. The Removable Media Drive and the IDE Interface 

FIG. 1A presents a functional block diagram of the 
removable media drive 210 of the present invention as 
implemented for an IDE interface 227 to the processor 220. 
The drive electronics are comprised of several subcompo- 
nents: a 40 pin IDE bus connection 328; a CPU 330, for 
example, an 8052; a 1k Data RAM memory 324 for execut- 
ing local programs; a 32k ROM memory 322 for storage of 
programs; a controller circuit 320, such as an AIC-7166 
manufactured by Adaptec, which controls buffer manage- 
ment of data to and from the media, media interface, and 
processor interface via the IDE bus; a Timing Processor for 
providing timing signals to the servo motors and the read/ 
write channel; motor control circuitry 334; an RLL encoder 
336 for writing data to the media; and an RLL decoder for 
reading data from the media. 

The removable media device is capable of communicating 
with the IDE controller card 227 (FIG. 1) via cylinder, head, 
and sector mode (hereinafter CHS mode) or logical block 
address mode (hereinafter LBA mode). In CHS mode, the 
controller card 227 presents a logical cylinder, head and 
sector from which data on the media is desired. The drive 
translates this information to a physical cylinder, head and 
sector to retrieve the data from the media. Importantly, the 
cylinder head and sector information set into CMOS 226 on 
the processor 220 defines the logical number of cylinder, 
heads and sectors on the drive and defines the translation 
used by the drive to determine where to physically retrieve 
the data on the media. In LBA mode, the controller card 227 
communicates with the drive 210 through a linear mapping 
of sectors, starting at sector 0 and continuing to the last 
sector depending on the capacity of the drive. 

FIG. 1B is a graphical depiction of the command block 
registers used in an IDE interface for communication 
between the processor 220 and the removable disk drive 
210. This set of registers resides within the controller 320 on 
the drive electronics. The command block registers 310 
comprise eight registers: the data register 311 for reading 
and writing data to the media; the error/features register 312, 
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which may contain the status of the last command executed 
by the drive or may be used to enable or disable features of 
the drive; the sector count register 313, which contains the 
number of sectors of data to be transferred on a read or write 
operation; the sector number register 314 which contains the 
starting sector number for media access in CHS mode and 
bits 0-7 of the LBA when operating in LBA mode; the 
cylinder low register which contains the low order bits of the 
starting cylinder address for media access and bits 8-18 of 
the LBA when operating in LBA mode; the cylinder high 
register which contains the high order bits of the starting 
cylinder address for media access and bits 16-23 of the LBA 
when operating in LBA mode; the device/head register 
which contains both device and sector addressing 
information, bit 6 is set to zero for CHS mode; and one for 
LBA mode, whenever bit 4 selects the device, and bits 3 
through © comprise the head address in CHS mode or bits 
24-27 of the LBA in LBA mode; the status/command 
register 318 which contains the status of the drive when read 
and is used to issue commands to the drive on writes. These 
registers are all defined in the ATA-2 specification and are 
used in the present embodiment according to that specifi- 
cation. 

When the processor 220 wants to communicate with the 
removable media drive 210, commands are sent to the 
command register 318. For example, to read a block of data 
from the drive, the starting sector address will be loaded in 
to the cylinder, head and sector registers 314-317, and a 
sector count will be loaded into the sector count register 313. 
To load the registers, register information will be transferred 
to the drive 210 via the disk controller card 227. The register 
information will be sent over the IDE bus connection 328 to 
the controller 320. The controller will load the registers with 
the data provided. The controller 320, in conjunction with 
the CPU 330 will issue the proper commands to control the 
read process. In particular, the instructions to move the 
heads to the proper location on the media will be issued by 
the CPU 330 to the motor control 334 and the timing 
processor 332. The data provided will be decoded via the 
RLL decoder 338 and transferred to the buffer RAM 326, 
while the controller 320 passes the information back to the 
processor 220 through data register 311. A similar process 
occurs on a write to the media. 

FIG. 1C graphically depicts the states of the removable 
media drive of the present invention. In the present 
embodiment, the state transitions are controlled by a soft- 
ware program executing on the CPU 330 in the drive 210. 
The drive 210 must internally deal with a host of states to 
deal with the possibility of media absence, media presence 
and other complexities. The state diagram of FIG. 1C 
describes the possible states that removable media drive 210 
will switch to internally. Moreover, based on these states the 
removable media drive will present information in the 
command registers in response to commands sent by the 
host. The commands that affect the states are ail media 
access commands (READ, WRITE, etc.), and BIOS diag- 
nostic commands (DIAG, RECAL, SEEK, VERIFY). 
Significantly, when the removable media drive 210 is in the 
VIRTUAL CARTRIDGE state 1000, the BIOS diagnostic 
commands are not processed by the drive, but instead 
indicate a good status (status register=50h). This forces the 
BIOS to recognize the drive as available to the system and 
ready for booting during the Power On System Test (POST). 
In any other state, the drive will process these commands 
normally (e.g., if the media is present, these commands will 
be processed as usual; if the media is not present, these 
commands will fail). 
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The drive distinguishes between the POST and normal PC 
operations. The distinction becomes necessary when no 
media is present during POST. After POST, when the 
removable media drive 210 is informed that the removable 
media driver is present in the processor 220, the drive 210 
can safely fail media access and diagnostic commands. At 
that point, the removable media driver will take the neces- 
sary steps to inform the Operating System about fail con- 
ditions. On the other hand, if the removable media drive 210 
is unaware of the presence of the removable media driver (as 
will be true at power on), it will not fail these commands 
because that would cause the BIOS to fail the drive test. As 
a result, the BIOS will exclude the removable media drive 
210 from the list of available drives. 

Determining the removable media driver’s presence in the 
processor 220 is complex from the removable media drive 
side of the interface. For example, the driver may have been 
loaded, but then the user pressed Ctrl-Alt-Del to warm- 
teboot the PC system 200. In such a case, the removable 
media drive 210 does not receive a hard reset (as on 
Power-On), but rather only a soft reset will be issued by the 
BIOS. The same soft reset could have been issued. to the 
drive after any failed command. For example, a read fault, 
followed by a legitimate soft reset to clear the error condi- 
tion would cause a similar condition. But in the case of a 
warm reboot the removable media driver is no longer in 
processor RAM memory. The removable media drive 210 
will recognize this situation and switch to the VIRTUAL 
CARTRIDGE state. 

Additional complexity arises when the media is changed. 
The removable media drive 210 will fail subsequent media 
access commands and set the media change bit in the error 
register. If the removable media driver is present in the 
processor 220, this failure will happen only once, because 
the removable media driver recognizes and informs the 
Operating System of the media change. However, if no 
removable media driver is present, the fail condition can not 
be recovered, especially after soft reset. In such a case, the 
BIOS (without the removable media driver) will see the 
error condition and will try to clear it by sending a soft reset 
to the removable media drive 210. 

The state machine depicted in FIG. 1C allows the remov- 
able media drive 210 to handle the complexities outlined 
above. To begin, the most reliable detection point is the soft 
reset. On warm reboot, the BIOS will send a soft reset to the 
drive. To distinguish between a soft reset generated by the 
driver in response to a failed command and a soft reset 
generated by the BIOS on a warm reboot, the removable 
media driver follows a soft reset that it generates with a DA 
command (a command specific to the removable media 
drive also referred to as “Get Media Status”). Thus, the 
removable media drive will determine that a soft reset 
followed by a DA command indicates the removable media 
driver 210 is still present in the processor 220. If the soft 
reset is not followed by the DA command, the removable 
media drive 210 will consider it a warm boot. 

It is desirable to unlock the door if the system is warm 
te-booted to allow the user to change the media. However, 
it is not desirable to unlock the door if there is a soft reset 
in response to a command error. For these reasons, a soft 
teset switches the drive 210 into a special wait state (1004, 
1006 or 1010). In these states, the removable media drive 
210 waits for the next action from the processor 220. The 
removable media drive will transition out of these states on 
any of the following events (indicated by 1100, 1101, 1103 
on the diagram): soft reset, READ LBAO, command repost- 
ing Media Change. If the removable media driver is present, 
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8 
and confirms its presence through the DA command, the 
door will not be unlocked, and the removable media drive 
210 will return to the state 1012 or 1016. Any other 
command sent to the removable media drive 210 will unlock 
the door, because the drive 210 will assume a warm boot is 
being executed by the processor 220. 

The states 1000 and 1002 are the initial states that the 
removable media drive 210 switches to on Power On. Before 
the removable media driver is installed in the processor 220, 
the removable media drive 210 will stay in these states 
depending on media presence. Before any processor 220 
access is made to the drive, the user can safely eject and 
insert media, and no fault condition will be generated by the 
removable media drive 210. However, after the processor 
220 accesses LBAO while the media is present, the drive 210 
cannot change the data returned to the processor 220 if the 
user ejects the cartridge or inserts another one. So, if the 
media is ejected after LBAO was accessed from the media, 
the removable media drive 210 will switch to the state 
1008—Fail No Media. In this state, any media access 
command will fail with the No Media bit set in the error 
register, and the drive will not allow further data retrieval. If 
the media is inserted, access is still inhibited by the state 
1007, Fail Media Change sticky. The Operating System will 
be unable to understand the media change condition, so the 
drive 210 will not make the new media available to the 
Operating System. The only way for the Operating System 
to switch the removable media drive 210 out of this state is 
to send the Acknowledge Media Change command, as 
defined in the ATA specification, or for the removable media 
driver to send the DA command. The main distinction is that 
any driver or utility can send the drive 210 an ACK 
command, but that is not enough to switch to the drive 210 
to the READY DRIVER state 1016. Such a switch requires 
a DA command. So, the ACK command will only clear the 
fail condition and return the removable media drive 210 
back to state 1002. If another eject happens, the drive 210 
will switch to state 1008 again. 

Il. The Boot Sequence 

FIG. 2 shows a flow chart of a PC boot sequence in 
accordance with the methods of the present invention. 
During the start sequence (referred to as “booting”), the 
goals are to ensure that the PC 200 is functioning properly 
and to load the operating system from the storage device 
subsystem 250 into memory for execution by the processor 
220. To achieve these goals, the processor 220 runs a BIOS 
program contained in the ROM 228 (step 10). The BIOS, in 
turn, tests the sub-systems of the computer (step 20). Then, 
the BIOS checks the disk drives that are indicated in the 
CMOS 226. Of particular relevance to the present invention, 
the BIOS will issue commands to the fixed disk drives 210, 
230 (step 30). 

According to an aspect of the present invention and as will 
be described in more detail below, if no media is present in 
the removable media drive 210, the drive 216 simulates the 
presence of media in order to satisfy the BIOS (the VIR- 
TUAL MEDIA state 1000 in FIG. 1C). The BIOS will then 
attempt to boot from the fioppy drive in a conventional 
manner, details of which are known and need not be present 
here. 

After the testing is completed, the BIOS checks for and 
executes ROM programs supplied by the interface controller 
cards connected to the various subsystems (step 35). When 
the PC 200 boots from a fixed disk 210, 230, the BIOS next 
requests the Master Boot Record (MBR) from the “C” drive 
(step 40). 

According to an aspect of the present invention, the 
removable media drive 210 can be configured as the “C” 
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drive to control the boot process and account for remov- 
ability. When configured as the “C” drive, the removable 
media drive 210 provides the processor 220 with a substi- 
tuted MBR in response to the BIOS request. After checking 
the substituted MBR and believing it to be an authentic 
MBR, the BIOS transfers control to it (step 50). 
Subsequently, the substituted MBR (hereinafter “Universal 
Boot Record or UBR”) gains control of the boot sequence. 

As will be described more fully below, the UBR is a 
special boot record that, according to an aspect of the present 
invention, takes control of the boot sequence. The UBR then 
reads a more complete boot program, universal boot pro- 
gram (UBP), from the removable media drive (step 60). 
According to a feature of the present invention, both the 
UBR and the UBP are provided from the ROM 322 residing 
on the removable media drive 210. Thus, even if no media 
is present in the drive, the UBR and UBP gain control of the 
boot sequence when the removable media drive 210 is 
configured as drive “C.” 

According to a further aspect of the present invention, the 
UBP determines where to find the boot sector and, 
consequently, the operating system, i.e., on drive “C” or “D” 
or elsewhere (step 70). Thus, unlike a conventional PC, 
which can only boot from drive “C,” a PC 200 configured 
with the present invention is capable of booting from any 
device capable of providing a boot sector, no matter what its 
drive address. After loading the boot sector, the UBP then 
replaces the pointer to the BIOS so that it can monitor the 
system loading process whenever certain BIOS calls are 
made (step 80). Control is then passed to the Boot Sector, 
and a seemingly conventional boot sequence resumes (step 
90). 

As will be described more fully below, if the operating 
system is MS-DOS, the UBP will awaken on certain pre- 
defined BIOS calls and attempt to attach the removable 
media drivers so that the removable media drive will prop- 
erly operate in the MS-DOS environment (step 100). After 
the removable media driver is fully attached to MS-DOS, the 
removable media drive 210 is fully configured and the rest 
of the MS-DOS system loads (steps 110-130). Significantly, 
the removable media drivers are accessible to MS-DOS, 
even though the drivers were not loaded by DOS. 

Now that the overall boot process has been described, 
each segment of the boot process wherein aspects of the 
present invention are employed will be described in further 
detail. 

A. Assigning a Drive Address (Virtual Cartridge) 

As indicated in FIG. 2 at step 30, during a preliminary 
stage of the boot sequence, the BIOS checks the ready state 
of all drives 210, 230 configured as fixed disk drives. FIG. 
2A provides a more detailed flow of the interaction of 
removable media drive 210 with the BIOS during this BIOS 
check stage. The steps outlined in FIG. 2A enable the system 
to recognize the drive 210 even if no media is present. 

In a typical system using an IDE disk controller card 227, 
the BIOS will issue commands to the drive 210, 230, such 
as READ, VERIFY, IDENT and the like. If an IDE drive 
fails to indicate a ready status, the BIOS will not assign a 
physical drive number (e.g., 80h, 81h) and no drive letter 
will be assigned by MS-DOS when the system completes the 
boot sequence. Moreover, if the drive configured as the 
master IDE drive is not ready, the slave drive will not be 
checked. The removable media drive may not be ready for 
access during the boot sequence because no media is 
present. However, after the boot sequence, a user may desire 
to insert media and access the drive. If MS-DOS has not 
assigned a drive letter, the media will not be accessible. 
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Thus, according to an aspect of the present invention the 
removable media drive 210 indicates ready during the boot 
sequence to satisfy the BIOS inquiries whether or not media 
is present. 

Before testing the fixed drives, the BIOS first checks the 
settings in CMOS 226 to determine the parameters of the 
IDE drive 210, 230. According to the present invention, the 
user should configure the removable media drive 210 to 
represent a minimum cartridge size (e.g., 25 megabytes— 
128 cylinders, 12 heads, 32 sectors). Correspondingly, the 
removable media drive 210 responds to tests in a VIRTUAL 
CARTRIDGE mode (see FIG. 1C state 1000), i-c., as if it has 
a minimum cartridge capacity. 

Referring to FIG. 2A, the BIOS sends a command to the 
removable media drive 210 (step 142). If the drive has media 
inserted (step 150), then the drive will perform all tests 
requested by the BIOS on the media as any normal fixed disk 
drive (step 160). If, on the other hand, no media is present 
in the drive 210 (step 150), the drive CPU 330 intercepts the 
commands and provides data to simulate the requested 
action. In this VIRTUAL CARTRIDGE mode, the remov- 
able media drive, then, will expect requests from the BIOS, 
which are designed to test the availability and readiness of 
the media. If the command is one of DIAG, RECAL, SEEK. 
or VERIFY (step 152), a response will be provided in the 
status register 318 and error register 312 indicating to the 
BIOS that the command was successful (step 162). If the 
command is INITP, IDENT or SET MULTIPLE (154), the 
command will be processed and success will be indicated in 
the status register 318 (step 164). Additionally, if the com- 
mand was IDENT, words 57-58 and 60-61 of the identifi- 
cation data are set to zero indicating that there are no sectors 
available (step 164). If the command is a read of the master 
boot record (step 156), an artificial master boot record is 
provided from drive ROM 322 (step 166). Requests to read 
from sectors other than the master boot record provide data 
as F6 hexadecimal (steps 158 and 168). Any other com- 
mands received will cause a failure to be reported in the 
status register (step 170). 

When the BIOS then checks the status register 318 (step 
144), if the command was successful, the BIOS will con- 
tinue testing the drive until all of the commands have been 
issued (step 146). After completion (step 148), the BIOS is 
satisfied that the removable media drive 210 is ready, a 
physical drive number will be assigned to the drive (e.g., 80h 
corresponding to drive letter “C”) and the boot sequence will 
continue. When the boot sequence is finished, the removable 
media drive 210 will be fully recognized and accessible by 
the BIOS and, subsequently, DOS. Importantly, if the 
removable media drive 210 is listed as the first fixed drive 
in the BIOS (Drive 0 or master), and an additional drive is 
connected to the same IDE controller card (drive 1 or slave), 
the second drive will also be tested and recognized. Thus, if 
the removable media drive 210 did not have a VIRTUAL 
CARTRIDGE mode, the other fixed disk drive 230 would 
not be recognized. 

B. Providing Boot Capability For Removable Media Drives 

After the BIOS has tested the removable media drive 210 
for availability, the boot sequence proceeds. Next, the BIOS 
will check for a floppy drive to boot. If a floppy diskette is 
inserted into the “A” drive, the BIOS will attempt to boot the 
operating system from that diskette. If no floppy is present, 
the boot will proceed to the first fixed drive, typically “C.” 
As with the floppy, a user may want to boot from the 
removable media drive 210. To provide this capability, the 
removable media drive 210 must be configured in CMOS 
226 as the first fixed drive in the system (i.e. drive “C”). This 


5,694,600 


il 
also requires the removable media drive 210 to be selected 
as the master (i.e., drive 0) on the IDE interface. 

Without the benefit of the present invention, in order to 
boot of off the removable media drive 210, media would be 
tequired to be present during all boot sequences. Moreover, 
the user would be required to always boot from the remov- 
able media drive 210 and any media replaced during the 
operation would have to have part of the operating system 
present. To alleviate these drawbacks, according to a further 
aspect of the presently preferred embodiment, a capability is 
provided to boot from any drive in the system. As will be 
described more fully below, this capability relieves the need 
to keep media in the removable media drive 210 during the 
boot sequence by detecting the absence of media and 
redirecting the boot sequence to another fixed disk drive 
(e.g., drive 230). 

1. Providing a Substitute Master Boot Record 

With the removable media drive 210 configured as drive 
“C,” the boot sequence proceeds. As indicated in FIG. 2 
(step 40), the BIOS requests a MBR from drive “C,” which 
conventionally contains a boot program of one sector in 
length. From the perspective of the removable media drive 
210, this request appears as a request for the sector at 
cylinder zero, head zero, and sector one (i.e., the cylinder 
registers 315, 316, set to zero, the head indicator bits in the 
device/head register set to zero, the sector number register 
set to one, the sector count set to one, and the command 
tegister set to read). Conventionally, the drive would then 
read the first sector from the media and transfer the sector to 
the processor 220. 

According to the present invention, however, the MBR is 
provided from ROM 322 rather than the media. This pro- 
viding of the MBR from ROM 322 is done according to one 
of two methods: if media is present, the MBR is read from 
the first sector, the partition tables are extracted and merged 
with the partition table of the replacement MBR stored in the 
removable media drive ROM 322, and the substitute MBR 
is returned; if no media is present, the substitute MBR is 
provided with an artificial partition table. According to 
either method, the normal MBR program code is replaced by 
a ROM based master boot record code stored in ROM 322 
(hereinafter referred to as the “Universal Boot Record” 
(UBR)), which allows a program residing on the removable 
media drive 210 to gain control of the boot sequence. 

In order to “trick” the BIOS into accepting the UBR as the 
real MBR, the UBR contains all of the required attributes, 
i.e., the last word of the sector contains the signature AA55 
hexadecimal. Thus, the BIOS assumes that the data provided 
by the removable media drive 210 is the MBR and passes 
control to the UBR. Once in control of the boot sequence, 
the UBR makes requests to the removable media drive 210 
to provide additional blocks of data, which contain a more 
complete boot program. The one sector long UBR is not of 
sufficient size to perform all of the required steps to allow 
booting from any fixed drive. Moreover, according to the 
presently preferred embodiment and as will be described 
more fully below, the UBP also contains the removable 
media disk driver that gets hooked to MS-DOS and provides 
the capability of handling the aspects of removability not 
support by MS-DOS disk services. 

2. Universal Boot Record Gains Control of the Boot Process 

FIG. 2B presents a flow chart of the function of the UBR 
as it executes on the processor 220. Initially, the UBR scans 
its partition tables at offset 0 (e.g., IBEh, 1CEh, etc.) to find 
an active partition (step 410). In general, there will be a 
single partition for the removable media. The UBR will call 
to the BIOS to retrieve the current drive settings contained 
in CMOS 226 (step 414). 
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Those settings are then used by the UBR to convert the 
“Partition Start Sector,” field contained in the partition table 
at offset 8, to CHS (step 418). Thus, when the UBR calls to 
read the boot sector in CHS mode, the UBR will read the 
proper sector from the drive. If the media capacity and 
format information for the removable media drive 210 were 
universal, the process of locating the boot sector would be 
straight forward. The values stored in the CMOS would be 
the values used to determine the location of the boot sector. 
However, the removable media disk drive 210 is designed to 
support a variety of media sizes (e.g., 100 megabytes, 200 
megabytes). Moreover, the media itself may have been 
initially formatted on a removable media drive from a 
variety of controller standards and thus the CMOS settings 
in the PC 200 for the number of cylinders, heads and sectors 
will not accurately reflect the values used on the PC in which 
the media was originally formatted. Because it is desirable 
to support the removable media regardless of the drive in 
which it was formatted, these differences must be taken into 
account. For example, if the drive in which the media was 
formatted is a SCSI drive, the CMOS settings would indicate 
64 heads, 32 sectors. By contrast, the IDE standard requires 
that the number of heads be less than 16. 

Next, it must be determined that this is a compatible drive 
i.e., that it is aremovable media drive containing the special 
boot software. A READ LONG command of LBA 0 is issued 
to the drive 210 (step 420). The drive returns the data 
requested along with the Error Correction Code (ECC). 
However, the removable media drive 210 returns a special 
tag field in place of the standard ECC (step 421). The tag 
field returned will contain four bytes of tag information “E,” 
“R,” UBP size in sectors, and a checksum, thus indicating to 
the processor 220 that a removable drive having the univer- 
sal boot capabilities is attached. 

From the perspective of the drive, if a READ LONG of 
LBA 0 is requested, the drive interprets this as a test of the 
drive for compatibility. Thus, the UBR from removable 
media drive ROM 322 is once again returned to the proces- 
sor 220. This time an ECC is appended with the special tag 
field. 

After the drive has been tested for compatibility and 
determined to be a proper removable media drive 210, the 
drive 210 is commanded to provide the UBP from its ROM 
322. According to a presently preferred embodiment, a 
WRITE LONG command is issued to the drive along with 
the special tag field embedded in the Error Correction Code 
field (step 422). The removable media drive 210 interprets 
such a command as an enable signal to provide the UBP. The 
next READ command issued is then interpreted by the drive 
210 as the signal to provide the UBP. 

To read the UBP, a READ command for the proper CHS 
of the boot sector is requested (step 424). The request is 
made through the disk access routines provided by the 
BIOS. When the READ command is received by the remov- 
able media drive 210, it should be interpreted by the drive 
210 to return the UBP. However, in the event an error occurs, 
the drive should interpret this as a read of the boot sector. In 
either event, the computer should boot. If the UBP is in 
control, the boot will occur according to the method of the 
present invention. If the boot sector is given control, a 
conventional boot will occur. 

Other methods can be used to accomplish the same goal 
of transferring the UBP from the drive ROM 322. For 
example on an IDE drive, the UBR can issue an FO hexa- 
decimal (defined by the present invention to be “UBP Load 
Enable”) into the command register 318. The controller 320 
will then transfer this command to the CPU 330, which will 


5,694,600 


13 
interpret it as a request for the UBP, and place the length of 
the UBP in the sector count register 313. The CPU 330 will 
tead the UBP from the ROM 322 and transfer the UBP to the 
Buffer RAM 326. The UBP will then be transferred by the 
controller 320 over the IDE bus to the processor 220, where 
it will be loaded into RAM 224. 

After the UBP is loaded into RAM memory 224 on the 
processor 220, the UBR will check the code to ensure that 
the code is complete. In particular, the signature of the last 
sector will be checked. A signature word of AAS5h indicates 
that this is the UBP (step 426). If the signature is incorrect, 
the first sector transferred will be checked to see if it is a 
valid DOS boot sector (step 428). If the first sector is a valid 
DOS boot sector, correct values will be placed in the boot 
sector image in memory to enable a boot. Specifically, the 
sectors per track field (offset 18%), the number of heads field 
(offset 1Ah) and the physical device field (offset 24h) will all 
be updated to reflect the proper values. The sectors per track 
and number of heads reflect the values stored in CMOS 226 
(step 430). A normal DOS boot should result. If no valid 
boot program is provided, a message will be displayed to put 
a bootable cartridge into the drive 210 (step 432), and an 
attempt is then made to re-load the Boot Sector. 

3. Control Passes to the Universal Boot Program 

FIG. 2C present a flow chart of the events that occur upon 
execution of the UBP by the processor 220. The UBP loads 
into memory and continues with the substituted boot 
sequence. However, the UBP was loaded into the location of 
the conventional boot sector. Now, areal boot sector must be 
read from the drive 210 or 230. Therefore, the UBP copies 
itself to a new location in memory, out of the way of the boot 
sector (step 500). Next, a genuine boot sector can be loaded 
from a bootable drive. 

All available controller cards 227 are tested for bootable 
drives (step 502). After all drives have been tested for 
availability, a “Get Media Status” command (DA 
hexadecimal) is sent to the removable media drive to deter- 
mine the availability of media. This command signals the 
drive 210 to leave the VIRTUAL CARTRIDGE mode (FIG. 
1C, state 1000) or READY NO DRIVER mode (FIG. 1C, 
state 1002). If the drive 210 has media present, then it 
transitions into READY DRIVER mode (FIG. 1C, state 
1016). Otherwise, the drive 210 transitions to a FAIL NO 
MEDIA state (FIG. 1C, state 1012). After receiving the Get 
Media Status command, the drive 210 reports the presence 
or absence of media in the status register 318 and error 
register 312. If there is an error, the drive 210 sets the status 
register 318 to 51 hexadecimal to indicate that bits are set in 
the error register 312. Bit one in the error register 312 
indicates no media present if set to 1 (step 504). As previ- 
ously indicated, the drive transitioned out of a pre-driver 
state. The drive 210 must be returned to a pre-driver state 
because the driver is not yet available. A soft reset will be 
issued by the UBP to the drive 210 to return it to a pre-driver 
state (state 1000 of 1002). 

After finding the available drives, the UBP reads the 
master boot records from each drive. These master boot 
records are then scanned for active partitions (step 506). If 
an active partition is found, the boot sector for that partition 
is loaded into memory as a preliminary check that the 
partition is bootable. If no active partition is found, then the 
boot sector of the first valid partition entry is read and 
checked for bootability. As partitions are found that have 
valid data, they are added to a list of available bootable 
partitions. Moreover, the BIOS is queried for available 
floppy drives and they are added to the list. After building 
the list of bootable drives and partitions, a message is 
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displayed to determine the users preference for a boot device 
(step 508). Booting proceeds by reading the boot sector from 
the drive requested. If no drive is requested, booting pro- 
ceeds from the removable media drive 210, if media is 
available. Otherwise, the next bootable drive is selected. The 
boot sector is loaded from the selected drive (step 509). 
After loading the boot sector, the UBP checks the partition 
type (step 510). If the boot sector is not an MS-DOS 
partition, control is passed to this boot sector and the role of 
the UBP is ended (step 512). 

If, on the other hand, the boot sector is an MS-DOS 
partition, the boot sector contains variables that reflect the 
number of heads, the number of sectors, and the physical 
drive number. These variables were written to the boot 
sector during the formatting process. According to an aspect 
of the present invention wherein booting from any drive or 
any cartridge in the removable drive is supported, these 
variables in the boot sector that are read into RAM memory 
224 are updated. The hard drive address is set to the current 
physical address of the hard drive. Additionally, for the 
removable media drive, the sector and head values are set to 
the correct values for the removable media, the sector and 
head values are set to reflect the current CMOS values. As 
will be described in detail below, anytime a new boot sector 
is read into memory by DOS, these parameters must again 
be updated by the removable media driver. 

In a typical fixed disk, these values will likely be correct. 
However, a user may have formatted the drive as drive “C” 
initially, but later moved the drive to drive “D.” In such a 
case, the physical drive letter stored in the boot sector will 
be inaccurate and must be corrected. However, in the case of 
removable media drives, the user very likely will have 
formatted the cartridge on a different drive. For example, the 
cartridge may have been formatted on a SCSI drive located 
at drive address “E.” Therefore, the boot sector variables 
must be patched. ; 

To make the appropriate changes to the boot sector image, 
the UBP gets the number of sectors and heads (from CMOS 
in the case of other fixed disk drives). Then, at offset 184 in 
the memory resident boot sector, the UBP writes the value 
of sectors per track. At offset LAA in the memory resident 
boot sector, the UBP writes the value of heads. Finally, at 
offset 24h of the memory resident boot sector, the UBP 
writes the physical drive number (e.g., 804 for “C,” 81h for 
“D”) (step 514). 

After the memory resident boot sector is copied and 
patched, DOS must access the patched table for subsequent 
disk accesses. Vector 41h generally, points to this portion of 
the memory resident boot sector (referred to as a “Disk 
Parameter Table”) The UBP replaces the address pointed to 
by vector 41h to point to the modified boot sector image, 
thus, ensuring DOS will use the correct values in making 
disk accesses (step 516). 

After all of the appropriate adjustments, control will pass 
to the newly loaded boot sector. Significantly, a portion of 
the UBP is a driver that remains resident after DOS has 
loaded, even when booting from another fixed disk drive. As 
is explained more fully below, to properly attach the driver 
to DOS, interrupts must be set to allow the UBP to “awaken” 
at the proper time to connect its driver to MS-DOS. 

IV. Loading the Device Driver 

The attachment of the removable media driver to DOS 
consists of two distinct parts. First, the UBP sets interrupts 
to monitor the DOS loading process, restores registers so 
that the boot process appears normal to DOS, then passes 
control to the boot sector. Second, during the boot sector 
execution and the subsequent DOS loading process, the UBP 
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monitors the loading process for the precise time when the 
removable media driver can be attached, and replaces the 
physical drive number in portions of DOS as it is loaded into 
memory to support booting from any drive. 

A. Hooking DOS Interrupts 

The desired boot sector was found and loaded, as 
described above. However, the driver to support the remov- 
able media drive 210 must adjust itself during the ensuing 
DOS loading process to allow DOS to recognize it after the 
DOS has fully loaded. FIG. 2C presents the flow diagram for 
loading the removable media driver according to the present 
invention. Essentially, the driver will move to an area of 
RAM in the top of conventional memory and encapsulate 
the DOS driver in IO.SYS associated by DOS with the 
removable media drive 210. Additionally, calls to INT 13 
and INT15 will be trapped and handled by the removable 
media driver. In order to hook the DOS driver properly, a 
significant portion of DOS must have been loaded by the 
boot sector. The moment when DOS has sufficiently loaded 
is determined on the fly during the DOS loading process. 
Referring now to FIG. 2C, the UBP loads the removable 
media driver portion of the UBP into a the highest available 
unused RAM 224 location and decrements the amount of 
available RAM memory by the size of the resident remov- 
able media driver (step 550). The removable media will 
reside at this location during the ensuing DOS operations, 
and the attachment process can proceed. An “Initialize 
Device Parameters” command is sent to the drive 210. When 
received the controller 320 stores the new values and uses 
those values for further communications with the processor 
220 (step 551). The disk service pointed to by INT 13 is 
replaced to point to the UBP driver (step 552). Thus, 
whenever disk services (INT 13) are requested, the UBP 
driver will intercept the call and execute. 

Once the interrupts are set, all registers in the processor 
CPU 222 are set as if a conventional MBR had loaded a 
conventional boot sector. In the present embodiment, 
wherein an Intel 80x86 is the CPU 222, the DS:SI registers 
are set to the partition table entry for the active partition; the 
ES:BX registers are set to the address of the boot sector in 
memory; the DH register is set to the data value of the first 
byte of the partition table entry; the DL register is set to the 
physical drive number (e.g., physical drive “D” equals 81h); 
and, register CX is set to the data from the second word of 
the partition table entry (554). After the registers are prop- 
erly set, control is passed to the genuine DOS boot sector 
(see FIG. 2 Step 90). 

B. Monitoring the DOS Loading Process 

The loading of MS-DOS must be monitored so that the 
UBP driver can attach itself to the DOS environment. In a 
conventional DOS booting sequence, the drivers are loaded 
by DOS. Therefore, DOS makes all the necessary adjust- 
ments. A user adds the required device driver to the CON- 
FIG.SYS file. Near the end of the boot sequence, DOS scans 
the CONFIG.SYS file for drivers to load. The drivers are 
loaded and properly attached to the DOS environment. Ifthe 
user fails to add the driver to CONFIG.SYS the device will 
not function properly. 

According to an aspect of the present invention, the 
removable media driver is loaded automatically and before 
DOS loading is complete. Thus obviating the need for the 
user to add a driver to the DOS CONFIG.SYS file. This 
automatic driver loading makes the integration of the remov- 
able media driver simple and transparent to the user. No 
additions to CONFIG.SYS are made. However, by loading 
the driver before DOS, the attachment of the driver to DOS 
becomes the responsibility of the driver. Thus, the driver has 
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the responsibility of performing all of the housekeeping 
functions that would conventionally be performed by DOS. 
Because the driver is loaded into the PC before DOS is 
loaded, it is too early in the boot process to attach the driver. 
However, before DOS has loaded other device drivers, the 
temovable media driver should already be available to the 
PC system. 

During the DOS loading process, each time an INT 15 is 
executed, the UBP is awakened (as described above, the INT 
15 pointer was replaced before control was passed to the 
boot sector). At each awakening, the UBP determines if 
enough of DOS has loaded to start the process of attaching 
the removable device driver to DOS. When the UBP has 
finished its determination, it makes adjustments to complete 
the driver attachment as needed, then calls the genuine INT 
15 routine to allow the requested function to occur. 

According to the presently preferred embodiment, to 
make the proper attachment of the driver, the UBP must 
distinguish between DOS versions of 5.0 through 6.22 and 
DOS version 7.0. As is described more fully below, that 
version distinction determines the adjustments necessary. 

The UBP follows an eight step process in making the 
attachment. First, if the INT 15 function was not CO then this 
is not the correct point in the loading process. Complete the 
INT 55 call and return. 

Second, get the return address from the stack. That offset 
value must be greater than 10h to prevent a memory pro- 
tection error on the ensuing steps. Thus, if the offset value 
is less than 10h, complete the INT 15 and return. 

Third, if the value of the data at the return address-4 is not 
equal to COB4h, DOS has not sufficiently loaded. Complete 
the INT 15 and return. 

Fifth, compare 6 bytes starting at the return address-12 to 
75h,02h,33h,COh,2Eh,A2h. If the values match this is DOS 
version 7.0. The UBP must then patch the boot drive letter. 

Sixth, the drive letter is pointed to by the return address-6. 
Before patching, the UBP checks the high byte at that 
address. It should be F8h. If it is then, the UBP puts the boot 
drive letter into the lower byte (note that in this case the 
drives are represented as “A” equal 0, “B” equal 1, etc.). 
After the drive letter is patched, the INT 15 call is made. 

Seventh, this may be a different DOS version. Compare 
the values of the 10 bytes starting at return address-14 to 
8Eh,D2h,BCh,00h,07h,FBh,5 1h,8Ah,E5h,50h. If the values 
do not match, make the INT 15 call and return. 

Finally, if the values match, then the drive letter must be 
patched. For earlier DOS versions, get the third word from 
the stack. If the high byte is F8h, then put the boot drive 
letter in the lower byte. 

If the boot drive patch was made, the UBP begins moni- 
toring the INT 15 calls for an INT 15 function 88 call. This 
is an indication that a sufficient portion of DOS has loaded. 
DOS is nearing the load point wherein the removable device 
driver may be attached. To make the final determination a 
new DOS service is monitored—INT 21. 

When DOS issues its first call to INT 21, the UBP 
awakens once again. At this time, IO.SYS is now loaded into 
memory and, because the pointers necessary to encapsulate 
the DOS disk services driver are now in place, DOS is stable 
enough to allow attachment of the removable media driver. 

To start the attachment process, the UBP must replace the 
driver that DOS has attached to the removable drive. DOS 
keeps the driver information in a Device Parameter Block 
(DPB). The DPB for all drives are kept together in a linked 
list with the first link pointing to the DPB for drive “A”, the 
second for drive “B”, the third for drive “C”, and so on. The 
UBP must find the DPB for the driver servicing the remov- 
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able drive—drive “C”, change the driver header to point to 
the new removable media driver and set the attributes to 
indicate a removable media drive. 

FIGS. 3A and 3B graphically depict the process of attach- 
ing the removable media driver to DOS. FIG. 3A represents 
the undisturbed memory configuration before the removable 
media driver is attached. To find the first DPB, a DOS 
general services call to INT 21 function 52 provides, at offset 
0, a pointer to a pointer to the DPB of drive “A.” At offset 
19h of the DPB is the pointer to the next DPB in the linked 
list. By following the linked list to the third DPB, the UPB 
can find the DPB of ali the drives recognized by DOS. 
Significantly, the removable media drive 210 must be drive 
“C” or the UPB would never have gained control of the boot 
process. Each DPB points to a driver header record (offset 
13h) where variables are stored pertaining to the driver. 

FIG. 3A illustrates the configuration after the removable 
media drive is attached to DOS. After locating the proper 
UPB, offset 134 points to the driver header record of the 
device driver servicing the removable media drive. The UPB 
locates the driver header record and copies it to local storage 
within the removable media driver memory allocation and 
sets the header offset within the DPB to point to the copied 
header. The attributes word is found at offset 4 in the header. 
The UPB then sets bit 11 of that attribute word so that a DOS 
routine examining the driver header record will understand 
that the removable media drive 21@ supports removability. 

In addition, the UBP changes the pointers to the strategy 
and interrupt routines of the DOS driver within the header to 
point to the removable media driver. Now the DOS driver is 
embedded within the removable driver. When DOS calls its 
driver, the removable media driver gains control first. 

The removable media driver is now hooked and the 
original INT 21 call that the UBP monitored to awaken is 
serviced and the UBP is unhooked from the INT 21. 

It is desirable to remain hooked to INT 21, as well as other 
DOS services, for example, INT 2F. Such hooks give the 
driver added capability and flexibility. However, the INT 21 
vector will not remain pointed to the removable media 
driver. While DOS continues to load, it will continuously 
refresh the INT 21 vector. Thus, destroying the ability of the 
removable media driver to trap INT 21 calls reliably. 

According to another aspect of the present invention, the 
removable media driver remains hooked to INT 21 via the 
trap capabilities of the CPU 222. When the vectors become 
stable (i.e., DOS has completely loaded) the tracing is turned 
off and INT 21 and other vectors can be replaced to hook 
back to the removable media driver. 

To accomplish this function using the CPU trap 
capabilities, the vector INT 1 is set to point to the removable 
driver and the trace flag is set. Thereafter, every instruction 
executed on the CPU 222 can be monitored by the remov- 
able media driver. Of course, this tracing can impose a 
severe efficiency penalty. To minimize the impact, the trac- 
ing is enabled at the last possible moment. This moment is 
before CONFIG.SYS is loaded. After that point, DOS 
repeatedly refreshes the INT 21 vector. Thus, when there is 
an INT 21 function 3D cali made with the DS:DX registers 
containing “\CONFIG.SYS” INT 21 can no longer be reli- 
ably captured by replacing its vector to point to the remoy- 
able media driver. Instead, the CPU trapping technique is 
employed. 

CPU trapping can be turned off once the INT 21 vector 
becomes stable. This occurs when an INT 21 function 48 call 
is made with the register BX containing FFFFh. So, the CPU 
trapping continues until these values are obtained. 
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or other INT vectors can again be reliably replaced to point 
to the removable media driver. 
¥. Operation of the Device Driver 

Conventionally, a device driver that handles drive com- 
munication would simply replace the DOS disk services 
with its own substituted disk services. However, DOS disk 
services developed in conjunction with DOS and contains 
many undocumented features. Thus, according to an aspect 
of the present invention, the removable media device driver 
enhances the features of the DOS disk services without 
replacing them. As will be described more fully below, this 
enhancement is accomplished by encapsulating the DOS 
disk service within the removable media driver. The remov- 
able media driver provides this enhancement by checking 
the disk services call for removability services and making 
the necessary extensions to support removability before 
calling the initially called DOS disk services routine. 

The main removability functions supported by the driver 
are “check media status” and “rebuild BIOS parameter 
block.” For typical fixed disk drives, DOS does not expect 
the media to change. Thus, “check media status” does not 
return a media change indication. Additionally, the DOS 
disk services will not access the drive to service a “rebuild 
BIOS parameter block” command because the media never 
changes. 

FIG. 2D depicts a flow diagram of the current removable 
media driver service. Initially, a call is made to the remov- 
able media driver. If the command is to “check media 
status,” the removable media driver intercepts the command 
and process it (step 602). In response, the driver issues a 
“Get Media Status” command to the removable media drive 
210, as described in detail above (step 612). The drive 210 
will report the status of the media in the status and error 
registers. If the media has changed, the removable media 
driver reports that change to DOS. DOS will subsequently 
make a “rebuild BIOS parameter block” call to the remov- 
able media driver. If the media is not present, this will be 
reported to DOS. DOS will respond by sending the user the 
conventional “ABORT, RETRY, FAIL?” message. 

If a “rebuild BIOS parameter block” command is 
received, the removable media driver services this call 
because the DOS device driver does not rebuild BIOS 
parameter blocks for fixed disk drives (step 604). The 
removable media driver reads the partition table and boot 
sector from the drive. Then it issues an IDENT command to 
the drive to get the number of heads and sectors and 
currently loaded media size (step 606). . 

Then the removable media driver saves the request struc- 
ture pointed to by the original strategy call and makes a call 
to the DOS device driver to rebuild its internal structures via 
a “set device parameters” call (step 608). When that call has 
completed, the removable media driver updates the BIOS 
Parameter Table pointed to by the previously saved request 
structure. In particular, at offset 18h in the BIOS parameter 
table, the removable driver writes the value of sectors per 
track. At offset 1AA in the BIOS parameter table, the driver 
writes the value of heads (step 610). 

All other commands are processed by the removable 
media disk drive as any conventional fixed disk. Therefore 
these commands are passed to the DOS fixed disk driver 
(step 614). When the command is processed control is 
returned to the calling program. 

As the foregoing illustrates, the present invention is 
directed to methods and apparatus for booting a computer 
system and loading drivers from a removable media disk 
drive. In a PC system that boots an operating system from 
a storage device, the present invention provides a means for 
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booting from a removable media drive. It is understood, 
however, that changes may be made to the embodiments 
described above without departing from the broad inventive 
concepts thereof. For example, while the method of the 
present invention is particularly well suited to an IDE 
interfaced removable media drive, the same method may be 
used to boot a PC system from a removable media drive 
connected to a different interface, such as SCSI. 
Accordingly, this invention is not limited to the particular 
embodiments disclosed, but is intended to cover all modi- 
fications that are within the scope and spirit of the invention 
as defined by the appended claims. 

. What is claimed is: 

1. In a storage device having removable media and a 
memory area, wherein the storage device is connected to a 
processor and wherein the processor performs a boot 
sequence to retrieve an operating system from the storage 
device, a method of commandeering the boot sequence, 
comprising the steps of: 

(a) receiving requests from the processor to determine the 

status and availability of the removable media; 

(b) if no removable media is available, providing a 
simulated response of successful completion to said 
requests such that the storage device presents an indi- 
cation that removable media is available; 

(c) if media is available, performing said requests upon 
said media; 

(d) subsequent to said test requests, receiving a read 
request to provide a master boot record from said 
removable media; and, 

(e) providing a substitute master boot record from said 
memory area on the storage device instead of the 
master boot record from the media such that said 
substitute master boot record will gain control of said 
processor when said substitute master boot record is 
executed on said processor. 

2. The method of claim 1 wherein said memory area on 

the storage device is a Read-Only Memory device. 

3. The method of claim 1 wherein said substitute master 
boot record provides for the boot sequence to continue from 
any storage device connected to the processor. 

4. In a storage device having removable media, wherein 
the storage device is connected to a computer system having 
a processor, wherein the processor tests the storage device 
by checking a status of the storage device during a boot 
sequence such that the processor will not access the storage 
device if the status indicates that the storage device is not 
ready during the boot sequence, a method of inducing the 
boot sequence to accept the storage device whether or not 
removable media is available, comprising the steps of: 

(a) receiving requests from said processor to determine 

the status and availability of the media; 

(b) if no media is available, responding to said test 
requests with a simulated status such that the storage 
device appears to have media available; and, 

(c) if media is available, performing said test requests 
upon said media. 

5. In a computer system having a processor with a 
removable media storage device connected to said processor 
via an IDE disk controller card, the storage device having a 
memory area and the processor executing a BIOS to boot an 
operating system, a method of interrupting a standard boot 
sequence to integrate the removable media storage device 
into the computer system: 

(a) starting the BIOS on the computer system; 

(b) providing responses from the storage device to BIOS 

initiated requests to test the availability of the remov- 
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able media storage device such that the storage device 
appears to the BIOS to have media available even if no 
media is available; 

(c) providing the BIOS with a substitute master boot 
record from the memory area of the removable media 
storage device in response to a BIOS initiated request 
for the master boot record from the media; 

(d) controlling the boot sequence from the substitute 
master boot record when the BIOS executes said sub- 
stitute master boot record; 

(e) extending the standard boot sequence capabilities by 
retrieving another program from one of said memory 
area and said removable media of the removable media 
storage device in response to said substitute master 
boot record requests; and, 

(f) retrieving a boot sector from one of the removable 
media storage device or another storage device. 

6. The method of claim 5 wherein said memory area on 

the storage device is a Read-Only Memory device. 

7. In a computer system having a processor, a BIOS and 
a first storage device-that accepts a removable media, said 
first storage device being in communication with said 
processor, a method of booting an operating system program 
into said processor from one of the first storage device and 
another storage device, comprising the steps of: 

(a) requesting a master boot record from the removable 

media of the first storage device; 

(b) receiving a substitute master boot record from a 
memory area on the first storage device; 

(c) signaling the first storage device that said substitute 
master boot record has gained control of said processor; 
and, 

(d) retrieving a boot program from said first storage 
device such that the booting can be completed from one 
of the first storage device and another storage device 
having a valid boot sector. 

8. In a computer system having a processor in commu- 
nication with a first storage device of the type that accepts 
a removable media, a method of installing a device driver in 
an operating system program during the booting of the 
operating system into said processor, comprising the steps 
of: 

(a) requesting a master boot record from the removable 

media of the first storage device; 

(b) receiving a substitute master boot record from a 
memory area on the first storage device; 

(c) executing said substitute master boot record such that 
said substitute master boot record gains control of said 
processor and retrieves the device driver from the first 
storage device; and, 

(d) executing said device driver on said processor such 
that said device driver monitors the operating system 
loading process and attaches itself to the operating 
system based on a predetermined state of the processor. 

9. In a storage device having removable media, wherein 
the storage device is connected to a processor and wherein | 
the processor performs a boot sequence to retrieve an 
operating system from the storage device, an apparatus for 
commandeering the boot sequence, comprising: 

(a) means for receiving requests from the processor to 
determine the status and availability of the removable 
media; 

(b) means for responding to said requests such that the 
storage device presents a status indicating that remov- 
able media is available when removable media is not 
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available such that said processor believes removable 
media is available; 
(c) means for performing said test requests upon said 
media when said media is available; 


(d) means for receiving a read request from the processor 
to provide a master boot record from said removable 
media; and, 

(e) means for providing a substitute master boot record 
from a memory area on the storage device instead of the 
master boot record from the media such that said 
substitute master boot record will gain control of said 
processor when said substitute master boot record is 
executed on said processor. 

10. The apparatus of claim 9 wherein said memory area on 

the storage device is a Read-Only Memory device. 

11. In a computer system having a BIOS, wherein the 
BIOS supports booting from a limited capacity removable 
media drive, a method of booting from a higher capacity 
removable media drive, comprising the steps of: 

(a) configuring the computer system such that the BIOS 
recognizes the removable media drive as a first avail- 
able fixed media drive; 

(b) indicating to the BIOS during booting that the higher 
capacity removable media drive has media available 
whether or not media is available in the removable 
media drive; 

(c) delivering a substitute master boot record to the BIOS 
when an initial request is made from the BIOS to the 
removable media drive for a master boot record from 
the media; 

(d) when the BIOS executes said substitute master boot 
record, loading additional programs by the substitute 
master boot record from the removable media drive 
such that additional operating system support is added 
for the removable media drive; 

(e) loading a valid boot sector; and, 

(f) passing control to said valid boot sector such that 
normal booting resumes. 

12. The method as recited in claim 11, wherein the step 

(b), comprises the steps of: 


(i) receiving requests from the BIOS to determine the 
status and availability of the removable media; 

(ii) if no removable media is available, responding to said 
requests such that the storage device presents a status 
and data indicating that removable media is available; 
and, 

(iii) if media is available, performing said requests upon 
said media. 

13. The method as recited in claim 11 wherein the step (c) 
further comprises the step of loading said substitute master 
boot record from a Read-Only Memory device within the 
removable media storage device. 

14. The method as recited in claim 11, wherein the step (d) 
comprises the steps of: 

(i) loading a boot program having a device driver portion 

from the removable media drive; 

Gi) passing control from said substitute master boot 
record to said boot program such that said boot pro- 
gram can search the removable media drive and other 
storage devices for at least one boot sector; 

(iv) setting said computer system such that said boot 
program can attach the driver portion of said boot 
program when a sufficient portion of an operating 
system is loaded. 
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15. The method as recited in claim 14, wherein the 
computer system has a CPU having at least one interrupt, 
and wherein the step (iv) comprises setting said at least one 
interrupt such that said boot program executes when said at 
least one interrupt is called such that said boot program can 
attach said driver portion to said operating system. 

16. The method as recited in claim 14, wherein the 
computer system has a CPU having a trace capability, and 
wherein the step (iv) comprises setting the trace capability to 
execute said boot program when a predefined instruction is 
executed on the CPU such that said boot program can attach 
said driver portion to said operating system. 

17. In a storage device for use in a computer having a 
processor, a method of booting an operating system into the 
processor, comprising the steps of: 


(a) storing a substitute master boot record in a first 
memory area in the storage device; 


(b) storing a boot program in a second memory area in the 
storage device; 

(c) receiving a request from thé processor for a master 
boot record; 

(d) providing said substitute master boot record from said 
first memory area such that said substitute master boot 
record gains control of the processor and requests the 
boot program from the storage device; 

(e) receiving a request from the processor for the boot 
program; and, 

(f) providing said boot program from said second memory 
area such that said boot program retrieves a boot sector 
from the storage device or another storage device 
connected to the processor. 

18. The method as recited in claim 17, wherein the storage 

device has removable media, comprising the further steps 
of: 


(i) receiving test requests from the processor to determine 

the status and availability of the removable media; 

Gi) if no removable media is available, responding to said 

test requests such that the storage device presents a 
status indicating that removable media is available; 
and, 

(iii) if media is available, performing said test requests 

upon said media. 

19. The method as recited in claim 17 wherein said 
memory area on the storage device is a Read-Only Memory 
device. 

20. The method as recited in claim 17 wherein said boot 
program provides for the boot sequence to continue from 
any storage device connected to the processor. 

21. The method as recited in claim 17 wherein the step (e)} 
comprises the steps of: 

@) signalling the storage device that said substitute master 

boot record has gained control of said processor; and, 

Gi) retrieving the boot program from the storage device 

such that the booting can be performed on any storage 
device having a valid boot sector. 

22. The method as recited in claim 21 wherein the 
signalling of step (i) comprises using READ LONG and 
WRITE LONG commands with signalling information 
embedded in place of error correction codes. 

23. The method as recited in claim 21 wherein the step (i) 
comprises using a command recognized by the drive as a 
enabling the boot program. 

24. In a computer having a processor and a storage device, 
wherein said processor has a BIOS program for starting a 
boot sequence that loads an operating system into the 
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processor from the storage device, a method of gaining 
control of the boot sequence from the BIOS and loading a 
device driver while booting an operating system, comprising 
the steps of: 


(a) setting said drive as the first fixed disk drive in the 


system; 

(b) storing a substitute master boot record in the storage 
device; 

(c) storing a substitute boot program in the storage device; 

(d) at system start-up, after the BIOS requests a master 
boot record, providing said substitute master boot 
record in place of the requested master boot record; 

(e) executing said substitute master boot record on the 
processor such that said substitute master boot record 
gains control of the boot process; 

(f) after the substitute master boot record gains control of 
the processor, retrieving and transferring control to said 
boot program; 

(g) after said boot program gains control of the processor, 
loading a valid boot sector; 

(h) executing the boot sector such that the boot sector 
loads an operating system; and, 

(i) monitoring the execution of the boot sector such that 
at a predetermined time during the loading of the 
operating system, the boot program regains control of 
the system and connects a portion of itself to the 
operating system as a device driver. 

25. The method as recited in claim 24, wherein the storage 
device is of a type that accepts a removable media, com- 
prising the further steps of: 

(i) receiving requests from the processor to determine the 

status and availability of the removable media; 

(ii) if no removable media is available, responding to said 
requests such that the storage device presents data and 
a status indicating that removable media is available; 
and, 

Git) if media is available, performing said requests upon 
said media. 

26. The method as recited in claim 24 wherein said step 
(b) comprises storing said substitute master boot record in a 
memory device. 

27. The method as recited in claim 26 wherein said 
memory device is a Read-Only memory device. 

28. The method as recited in claim 24 wherein the step (g) 
comprises loading the boot sector from any storage device 
connected to the processor. 

29. The method as recited in claim 24, wherein the 
processor has a CPU having at least one interrupt, and 
wherein the step (i) comprises setting said at least one 
interrupt such that said boot program executes when said 
boot sector makes a call to the at least one interrupt. 

30. The method as recited in claim 24, wherein the 
processor has a CPU having a trace capability, and wherein 
the step (i) comprises setting said trace capability to execute 
the boot program when a predefined instruction is executed 
on the CPU. 

31. In a storage device of a type that accepts a removable 
media, wherein the storage device is connected to a proces- 
sor having a BIOS and wherein the BIOS performs a boot 
sequence to retrieve an operating system from the storage 
device, an apparatus for commandeering the boot sequence, 
comprising: 
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(a) storing means for storing a program code on the 
storage device such that said program code can replace 
a portion of the boot sequence; 


(b) receiving means in communication with said proces- 
sor for receiving requests from the processor to deter- 
mine the status and availability of the removable media 
and to provide a master boot record from said remov- 
able media; 

(c) means in communication with said receiving means 
for responding to said requests such that the storage 
device presents data and a status to the BIOS indicating 
that removable media is available when no removable 
media is available; 

(d) means in communication with said receiving means 
for performing said requests upon said removable 
media when said media is available; 

and, 

(e) means in communication with said storing means for 
providing a first portion of said program code on the 
storage device instead of the master boot record from 
the removable media in response to requests to provide 
a master boot record, such that said program code 
record will gain control of said boot sequence allowing 
the boot sequence to proceed from a storage device not 
supported by the BIOS. 

32. The apparatus as recited in claim 31 wherein said 

program code comprises: 

a first portion containing a substitute master boot record 
conforming to a master boot record format recognized 
by the BIOS; and, 


a second portion containing a boot program, wherein said 
boot program comprises a modified boot sequence 
program portion and an operating system extension 
portion. 

33. The apparatus as recited in claim 31 wherein said 
program code is stored on the storage device in a memory 
device. 

34. The apparatus as recited in claim 33 wherein said 
memory device is a Read-Only memory device. 

35. In a computer system having a BIOS, wherein the 
BIOS supports a limited capacity removable media drive as 
a boot device for loading an operating system, a method of 
supporting a higher capacity removable media drive as a 
boot device comprising the steps of: 

(a) configuring the computer system such that the BIOS 
recognizes the removable media drive as a first avail- 
able fixed media drive; 

(b) delivering a substitute master boot record to the BIOS 
when an initial request is made from the BIOS to the 
removable media drive for a master boot record from 
the media; 

(c) when the BIOS executes said substitute master boot 
record, loading additional programs into the computer 
system from the removable media drive such that a 
removable media function is recognized by the oper- 
ating system while the removable media drive is con- 
figured as a fixed media drive. 
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